1. Technical Field
The present invention relates generally to techniques for enabling users on the Internet to securely access resources in various locations. More specifically, the invention relates to a web-based access control technique that uses a per-request client-generated token to authenticate that a request for access to a protected resource is properly bound with a given user identity.
2. Description of the Related Art
Information technology (IT) systems and the Internet have fueled the growth of the current global economy. While IT systems have significant benefits, at the same time they pose potential security threats from unauthorized third parties. Indeed, the lack of security in modern IT systems has emerged as a threat to the integrity of global computer networks. To deal with this problem, IT systems provide a number of known services: data authentication, data confidentiality, entity authentication, and authorization, among others. Data authentication typically consists of two sub-services, data integrity and data origin authentication. A data integrity service is used to convince a receiver of given data that the data was not changed during transit. Data origin authentication proves to the receiver the identity of the real sender. Data confidentiality protects against disclosure of data during transmission. Entity authentication provides the system with proof that a certain entity is who they claim to be. Authorization is the act of determining whether an authenticated entity has the right to execute an action. Authorization and authentication thus are dual services. To be able to provide authorization, it is necessary to determine who the entity is (e.g., by entity authentication). Authorization, in general, consists of two separate stages: providing privileges (authorization credentials) to a particular entity, and using these privileges in combination with access decision rules at the resource to determine if access should be granted to the entity.
It is becoming increasingly important to allow users to securely access resources in various locations. For example, an employee of a company may need to access documents from a main office and also from a local office while located at home or at a customer's premises. A browser has become the tool of choice in such scenarios. Through the standard Hypertext Transfer Protocol (HTTP), the browser can be used to access any HTTP-enabled server (commonly called a Web Application Server (WAS)) and obtain access to the resource. Most browsers provide security through the Transport Layer Security (TLS) protocol. This protocol allows both the browser and the WAS to authenticate each other (i.e. to prove their identity to each other), and it also provides data protection (data integrity and data confidentiality) for data in transit between them. The strongest form of authentication provided by the TLS/SSL protocol is client- and server-side certificate authentication. Such authentication requires the client (the browser) and the server (the WAS) to each have a private/public cryptographic key pair, and associated certificates. Public key authentication maintains a binding between a user's identity and a public key that can only be unlocked by the associated private key, and these protocols are used to provide mutual authentication.
If the user at the client desires to access a URL on the server that can only be accessed by an authenticated and authorized user, however, there must be some process to determine authorization. SSL does not provide authorization (or other security services) to the Web Application Server. Therefore, although the server can be sure of the user's identity via authentication, it does not know the user's privileges.
One attempt to solve the authorization problem is to pass authentication information within a cookie. As is well-known, a cookie is a file that is set by a server to customize data to a particular user's web browser. Cookies thus provide a degree of “state” to HTTP, which is otherwise a stateless protocol. When a user of a client machine visits a web server, the server may return a cookie to the user's browser. When a cookie is set as part of a HTTP transaction, it may include the path the cookie is valid for, the cookie's name and value, and other optional attributes, such as the cookie's expiration date. By default, the browser automatically stores the cookie data, typically without giving the user the option or knowledge of it being done. Because the cookie is stored, it is often referred to as “persistent.” Later, when the user revisits the server, the cookie is sent with the request, thereby identifying the user to the server.
Thus, the typical persistent cookie set on a client's browser identifies the user to the server. In prior art solutions, such as those provided commercially by enCommerce GetAccess™ and Netegrity SiteMinder™, authentication data is forwarded within a persistent cookie when the client browser issues a request for a protected resource to the server that set that cookie. Such an approach, however, is insecure because it enables an attacker to equate possession of the cookie with the user's authorization (i.e. a proof of identity) to access the protected resource. As a consequence, these prior art schemes are highly susceptible to replay attacks wherein one who acquires the identity cookie can simply assert it to gain access to the protected resource.
The present invention addresses this problem.